home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / hardware-part1 / 5030 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  3.1 KB
  1. Path: comma.rhein.de!serpens!not-for-mail
  2. From: mlelstv@serpens.rhein.de (Michael van Elst)
  3. Newsgroups: comp.sys.amiga.hardware
  4. Subject: Re: 80 MIPS with 1260 Explaination
  5. Date: 19 Feb 1996 12:28:29 +0100
  6. Organization: dis-
  7. Message-ID: <4g9mst$79l@serpens.rhein.de>
  8. References: <kluebke.14.824124623@mi.uni-koeln.de> <734.6617T840T985@Th0r.foo.bar> <4g9hjk$ah6@percy.cs.bham.ac.uk>
  9. NNTP-Posting-Host: serpens.rhein.de
  10.  
  11. R.D.Martin-CSSE94@cs.bham.ac.uk (Rich Martin) writes:
  12.  
  13. >If any one of these instructions relies on the result of an instruction further
  14. >on in the pipeline, then the whole system has to be stalled while the
  15.  
  16. Just the pipeline that depends on results to be computed has to be stalled.
  17.  
  18. >The Susperscalar architecture also compounds this problem. By having multiple
  19. >copies of the same CPU in the same chip
  20.  
  21. It doesn't have multiple copies of the same CPU in the same chip. It does
  22. have replicated processing units though.
  23.  
  24. >pipeline. If the 68060 had four copies (I don`t know exactly how many copies
  25. >it actually has) of the CPU
  26.  
  27. It has two integer and one floating point pipeline.
  28.  
  29. >another instruction in the pipeline, causing ALL copies of the CPU to be
  30. >stalled while the results are obtained from instructions further on.
  31.  
  32. I wonder where you got this nonsense from.
  33.  
  34. >Loops also cause a problem as the processing of the conditions of these loops
  35. >happens about half way through the pipeline, therefore when the CPU finds that
  36. >it has to branch to a different address, it has already loaded and started
  37. >execution of another 8 instructions, therefore effectively wasting these
  38. >instructions which have to be dumped.
  39.  
  40. Dumping these instructions would be the naiv approach. Some CPUs with deep
  41. pipelines do this. But more recent CPUs (including the 060) can decode and execute
  42. branches early. The 68060 has a branch prediction cache that enables it to
  43. "guess" the program flow correctly most of the time. The effect that you describe
  44. is therefore pretty rare.
  45.  
  46. >explains why somtimes turning the superscalar off can increase performance
  47. >(less pipelines stalls due to there being less instructions being executed
  48. >simultaniously)
  49.  
  50. This is again nonsense. Pipeline stalls happen with one or two pipelines. Going
  51. to a single pipeline may reduce the number of stalls but that just says that
  52. two pipelines _may_ be as slow as a single one. However, most often they are
  53. faster. Two pipelines are never slower than a single pipeline (unless the
  54. CPU designer goofed).
  55.  
  56. >It is perfectly possible to get the 68060 to execute 82.5 MIPS. The secret is
  57. >to compile a load of rubbish.
  58.  
  59. Or average programs. If the 68060 could execute two instructions per cycle all
  60. the time you would see 100 MIPS (at 50MHz).
  61.  
  62. >  for single thread sequential instruction execution. New versions of
  63. >  compilers are needed which reorganise instructions to allow these new
  64. >  breed of CPU`s to run at full throttle.
  65.  
  66. This is of course true but you are exaggerating the effects completely.
  67.  
  68. -- 
  69.                                 Michael van Elst
  70.  
  71. Internet: mlelstv@serpens.rhein.de
  72.                                 "A potential Snark may lurk in every tree."
  73.